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Several new hardware systems intended for, or adaptable to, standalone packet 
switch use have appeared on the market in 1990. These include the Grace 
Pa&Ten, the Kantronics Data Engine, and the soon to be available AEA PS-186. 
One obvious use for these systems is implementation of a TCPIIP-based amateur 
packet network. This paper discusses some of the design issues uncovered in 
porting the KA9Q TCPIIP package to a standalone hardware environment, and 
will touch on some tails of the implementations available now (or soon) for 


each of the mentioned hardware systems. 


Background 


For several years, Phil Karn KA9Q has spear-headed 
an effort to develop software based on the TCP/IP 
internetworking protocol suite for use on amateur 
packet radio. The “NET” package has enjoyed increas- 
ing popularity in countries worldwide. 


As the number of users has grown, it has become in- 
creasingly obvious that certain limitations in the 
base software need to be addressed in order to permit 
the development of networks. Paramount among 
these are the use of static routing in most NET in- 
stallations, and the dependence on end-user nodes to 
serve a dual function as network routers or gate- 
ways. 


In some areas, the separation of end user and network 
gateway (or router) functions has been accomplished 
by reliance on existing TNC-2 based NET/ROM in- 
stallations to provide network routing and "reliable" 
network service. This approach has helped to point 
out deficiencies in the routing algorithms and imple- 
mentation used in NET/ROM, and has resulted in 
very poor performance in the areas where NET/ROM 
switches are configured in a single-port configura- 
tion, against all recommendation. In other areas, ex- 
isting hardware platforms such as IBM PC clones 
and Atari ST systems have been pressed into service 
running the existing, standard NET software. This 
can be a very functional configuration from the stand- 


points of hardware availability and cost, software 
availability, and familiarity to network administra- 
tors. It can also be a real hassle, for reasons ranging 
from the lack of useable network routing and remote 
system management capabilities, to the seemingly 
mundane but very annoying issues of temperature 
range and power availability at switch sites. 


The advent of more powerful digital processing hard- 
ware targetted for the amateur packet radio environ- 
ment clearly is an attempt to address some of the 
problems related to use of existing user hardware 
platforms. | Unfortunately, the new hardware ad- 
dresses less than half the problem. The KA9Q 
TCP/IP software must be ported to these platforms, 
and some of the original software’s design limita- 
tions, which are quite reasonable in an end user’s sys- 
tem but are unworkable for a standalone diskless 
mountaintop switch, must be addressed and resolved. 


Understanding the network model envisioned by the 
authors may help explain our motivation in develop 
ing NOS-based packet switches. In Figure 1, we 
show the typical ‘‘cloud-model” of a network. At- 
tached to this network, and providing access service 
to several local user bases, are several switches 
Each switch provides connectivity for zero or more 
AX.25 “terminal nodes” (as in TNC, or Terminal 
Node Controller), zero or more TCP/IP-based _ ser- 
vice providers (larger DOS or Unix machines), and 
zero or more TCP/IP-based user machines. 
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Figure 1: Our Model of an Amateur Packet Network 


The most important points about this diagram are 
that individual users and their machines need know 
nothing at all about the topology of “‘the network’’, 
and that a switch can provide service to any number 
of AX.25 or TCP/IP users. 


For the TCP/IP users, operation is exactly as might 
be expected. Sessions can be initiated to any number 
of servers, other systems can initiate sessions to lo- 
cal servers, etc. Adding a new user’s host at maxi- 
mum requires knowledge of the local switch address, 
and even thaf may not be required if user nodes run 
automated routing protocols too. Connections are es- 
tablished through the network by knowing only the 
address or symbolic name of a remote system, and 
the service desired on that system, which could be 
further simplified by the addition of a location bro- 
ker on the network. 


For an AX.25 user, the local switch appears to be 
the service provider. A user connects to the local 
switch with a normal AX.25 connection, and is pre- 
sented with a menu of available services. Upon se- 
lecting a service, a TCP-based connection is automati- 
cally opened from the local switch, across the net- 
work, to a remote service provider. Services could 
include the ability to login to a BBS or Unix ma- 
chine, where a full range of options exist. Or, ser- 
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vices could be as directed as obtaining the current 
weather report from the National Weather Service, 
looking up a callsign in an electronic callsign server 
database, etc. The important point is that AX25 us- 
ers are fully supported as network citizens through 
the terminal-serving capability of their local switch. 


The implementation of KA9Q’s NOS TCP/IP soft- 
ware on the platforms discussed in this paper has be- 
come commonly known as ‘““NOSINABOX”’, and 
will be referred to by that term for the remainder of 
the paper. 


Issues 


The initial implementation of NOSINABOX has fo- 
cused on the fundamental changes required in the 
KA9Q TCP/IP package to allow it to function in an 
environment without disk drives, operating systems, 
and direct human intervention. This has involved dis- 
abling services that make no sense in a standalone en- 
vironment, rewriting facilities that are necessary re- 
gardless of environment but which depend on re- 
sources unavailable to us, and adding new 
capabilities that are uniquely necessary in a standal- 
one, remote hardware environment. 


The NOS software package includes protocol support 


for a variety of functions that only make sense in the 
presence of users, file systems, or both. These in- 
clude the FTP file transfer protocol client and serv- 
er, the SMTP electronic mail client and server, and 
the Finger server among others. Phil provides a com- 
pile-time mechanism to eliminate all servers from 
the package, but additional effort was required to lo- 
cate and disable code for nonsensical clients. 


One of the features of NOS versions of the KA9Q 
software is the ability to query domain name servers 
such as BIND for hostname to IP address transla- 
tion. Unfortunately, the stock name server client 
provided in NOS assumes the availability of a file 
system for caching the results of previous name que- 
ries. This code required a major rewrite, and includ- 
ed modifications made by PAOGRI and others to the 
stock NOS implementation. 


File system references also appeared in the initial 
configuration section of the software. In a PC or 
workstation environment, NOS loads configuration 
information from a disk file that the user provides. 
Considerable effort was expended to provide funda- 
mental configuration from ROM in all versions of 
NOSINABOX. Because we take advantage of special 
hardware features available on the different systems, 
this is discussed further in a later section. 


The standard NOS software was written assuming 
that a keyboard and display local to the processor 
would be used as a “console” for the package, provid- 
ing a configuration and debugging interface to the 
software. This is not true in most packet switch en- 
vironments, where the switch lives on top of a 
mountain reachable only on snow-shoes much of the 
year, or high on a tower requiring professional assis- 
tance to access. Fortunately, as part of the NOS re- 
write, Phil based the console interface to the soft- 
ware on the same “sockets” mechanism used to at- 
tach applications to networking services. It was 
therefore relatively easy to provide a mechanism for 
remotely attaching to the console over the network. 
Rudimentary but long-term inadequate security for 
this facility is provided in the initial release. 


Implementation-Specific Issues 


Since the author’s efforts in developing standalone 
versions of NOS have been carried out independently 
due to differences in the hardware platforms in- 


volved, and geographic location, the actual feature 3 


sets provided by the implemented code are somewhat 
different. However, considerable effort has been ex- 
pended to ensure that at least philosophically the ver- 
sions of NOSINABOX are aligned in such a way as 


to provide compatability for future development of 
Dew features. The following paragraphs outline 
sane of the software features of each NOSINABOX 
version as of this writing. 

Grace PackeTen 


Because the Grace Communications PackeTen is based 
on the Motorola 68302 “Integrated Multi-Protocol 
Processor” instead of the Intel platform traditional- 
ly supported by KA9Q’s NOS, much effort was ex- 
pended porting the code to the new processor. This 
effort involved both making a standalone version of 
the code function, and optimizing the software to 
take advantage of powerful new 68302 features. The 
resulting version of NOSINABOX has been dubbed 
*"NOS302". 


NOS302 is the NOSINABOX version most fully de- 
veloped at this time. In addition to the feature set 
neccessary for minimal standalone operation, the 
NOS302 system provides: 


1. Software Watchdog Function 


This feature implements a software sanity check 
within the NOS package. Since a remote packet 
switch is by definition not easily accessable, it 
is imperative that some form of dynamic soft- 
ware integrity test be performed during normal 
operation. The purpose of this test is to prevent 
a system which has suffered a software or firm- 
ware failure from “‘going off in the weeds” and 
becoming nonfunctional forever, requiring some 
poor soul to reach the site and manually restart 
the system. This "NOS independent’ software 
‘“‘watches” the system software, and if for some 
reason NOS is not running through it’s normal 
routine, the system is restarted with a hard re- 
set. 


2 EEprom Configuration 


Since amateur packet switches are usually inac- 
cessable, they must be capable of surviving a 
power glitch or outage, rebooting to a known 
functional state appropriate for the site. Since 
the PackeTen switch hardware provides non-vola- 
tile memory in the form of EEPROM, menu 
driven software is provided for configuration of 
such options as IP address, AX25 address, link 
definitions, and other neccessary site specific in- 
formation. 


Attachable / Detachable Console Port 


In order to avoid wasting one of the serial links 
for use as a local console during operation as a 
standalone switch, a “Console” device was devel- 
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oped which can be attached and detached just like 
all other links. This allows a remote switch to 
use all links during normal operation, but if on- 
site service of a node is required, a simple jump 
er strap will configure one of the ports as a lo- 
cal console for debugging. 


Scatter Gather Transmit 


This feature involves the use of an advanced 
68302 capability to dynamically build a transmit 
frame ‘“‘on tbe fly’ from a list of buffer point- 
ers. The major advantage of this capability is 
that the data does not have to first be copied 
from NOS’s "mbuf" chains into a contiguous da- 
ta frame area before transmission, thereby de- 
creasing processor overhead, and increasing 
throughput on a link. It is Worth noting that 
KA9Q’s approach to the problem of layered pro- 
tocol frame construction, namely mbuf chains, 
fits perfectly with the design of the 68302 serial 
communications controllers. His design al- 
lowed the “scatter gather” feature to be imple- 
mented relatively easily, and efficiently. 


Receive Mode Buffer Chaining 


Receive buffer chaining is another very impor- 
tant feature of the 68302 platform. The 302 se- 
rial channels are programmed with a list of 
available receive buffers. Then they begin to ac- 
cept incoming frames on the link. Upon com- 
pletion of a received frame, they simply mark 
the frame as ready for processing, and then pro- 
ceed, utilizing the next available receive buffer. 
All of this functionality is performed with no 
main processor intervention, or interrupt service 
required. Since the serial channel’s buffer chain 
list is up to eight (8) buffers deep, the main pro- 
cessor is only required to service a receive inter- 
rupt every 8 frames in order to prevent receive 
data overrun on a link. 


Software Timer Services Added to NOS. 


It was considered important in the 68302 NOS 
implementation to be able to handle “multiple” 
high speed da&a links, without the use of waste- 
ful polling loops for such things as 
keyup/keydown radio control. Therefore soft- 
ware programmable timer services were added to 
NOS to allow the programmer flexibility in 
writing device driver timing routines. 


Automatic Power Conservation Mode 


One of the features of the MC68302 processor is 
the ability to cut it’s power consumption from a 


typical 60 ma down as bw as | ma in it’s low- 
est power mode. The current NO$302 release 
1.2 implementation supports this type of opera- 
tion, allowing consumption to be reduced by ap- 
proximately half, to around 30 ma, during idle 
periods between received packets. 


Kantronics DE and AEA PS-186 


NOSINABOX for the Kantronics Data Engine and 
AEA PS-186 is under development at the time of 
this writing. Because the processor used (V40 and 
80C 186, respectively) and I/O hardware configura- 
tion (V40 DMA to 8530, and NEC DMA to 8530, 
respectively) are so similar, the two platforms are 
being treated as functionally equivalent, differing 
only in the number of ports (2 or 4) that are provid- 
ed in addition to the dedicated console port. 


Despite the inclusion of battery-backed CMOS 
RAM capability on both of these systems, the ini- 
tial release of NOSINABOX will probably include 
a configuration utility intended to customize the 
ROM images to reflect configuration information 
for a given site. Configuration changes will of 
course be possible after boot from the system con- 
soles. 


The initial release also will not take advantage of 
the DMA capabilities of these systems. Because the 
DMA controllers used do not provide a “scatter 
gather” chaining mode identical to the 68302 version, 
additional effort will be required to interface the 
NOS mbuf handling to DMA buffers for each port. 
For this reason, initial performance of these two 
platforms in interrupt-driven operation will be far 
from spectacular. 


Both the AEA and Kantronics platforms include 
hardware watchdog functionality, and NOSINABOX 
will use this functionality to force a hardware reset 
after software crashes. 


Future Directions 


Once fundamental hardware-specific issues are re- 
solved, the authors hope to integrate the two cur- 
rently divergent implementations of NOS for stan- 
dalone hardware into a single NOSINABOX environ- 
ment for multiple hardware platforms. It is highly 
likely that the Grace PackeTen system will always 
be “one step ahead”, since it is a commercial product 
with TCP/IP protocol support provided by the manu- 
facturer. The TCP/IP support for the AEA and 
Kantronics products is currently available due to en- 
tirely volunteer effort. 


A growing concern in the commercial and education- 
al network markets that is or will soon be mirrored 
in the amateur packet environment is the issue of net- 
work monitoring and management. The SNMP Sim- 
ple Network Management Protocol has recently 
come into wide use as the mechanism of choice for in- 
terrogating and controlling network entities. Sever- 
al vendors are now producing slick, graphically-oni- 
ented user interfaces for network management that 
rely on the SNMP protocol for communication with 
diverse networking hardware systems from multiple 
manufacturers. The effort required to implement at 
least a subset of SNMP target functionality seems 
quite acceptable, and it is highly likely that we will 
add SNMP support in a future release of NOSIN- 
ABOX. 


Considerable room for experimentation exists in the 
area of dynamic route determination. Fred Gold- 
stein, K1]O, has drafted a specification for a proto- 
col called RSPF, or Radio Shortest Path First. A 
preliminary implementation for NOS was written 
some months ago by Anders Klemets, SMORGV, and 
we are currently investigating including the RSPF 
code in the next NOSXNABOX release. RSPF has 
several features that make it an attractive potential 
alternative to the routing provided by NET/ROM 
and the RIP protocol currently included in NOS. 
One of the keys to automatic, dynamic route determi- 
nation on radio links is the issue of determining link 
quality, and this is an area that will no doubt be ad- 
dressed at great length over time. 


Currently, a very simplistic approach is used to 
“secure” the remote system administration facility. 
An alternative that intrigues the authors is the adop- 
tion of an IP-level option to cypher-checksum each 
frame sent on a secure connection. This approach in- 
volves encrypting each packet as it is assembled for 
transmission, calculating the checksum of the en- 
crypted packet., and transmitting it along with the 
plaintext packet and normal data corruption check- 
sum. By performing the same process on incoming 
packets, a receiver could know positively whether 
the sender knew a pre-negotiated key, thereby validat- 
ing control packets as coming from an authorized 
control station. This is a clearly legal use of encryp- 
tion for authentification purposes accepted by the 
FCC, with no restrictions since the actual data con- 
tent of each packet is sent in cleartext. An imple- 
mentation of this option, and a requirement for use 
of the option for remote sysop functions, would be a 
very secure way to control access to the configura- 
tion of a switch site. 


Each of the hardware platforms discussed in this pa- 
per include some mechanism for the inclusion of cus- 
tom, ‘‘expansion’”’ hardware. One possible use of this 
facility would be to drive hardware interfaces for te 
lemetry and control. It might be much easier to ob- 
tain permission to co-locate a switch with an exist- 
ing voice repeater facility if added value could be of- 
fered in the farm of a secure remote control and 
monitoring station for repeater equipment, power 
equipment, or weather data collection hardware, as 
examples. This area of functionality will be investi- 
gated for future releases of NOSINABOX, either as 
support for specific future hardware add-ons to the 
existing platforms, or perhaps as a generic interface 
for driving custom hardware at the I/O address and 
data level. 


The exact performance of NOSINABOX on all of 
these hardware platforms is not yet known. How- 
ever, the PackeTen has as of this writing been placed 
in service running 56 kb/s fullduplex radio links as 
well as having been tested with 2 megabit/s full-du- 
plex wire-line links. In one configuration it has si- 
multaneously supported six (6) 56 kb/s links, two 
(2) links at 9600 and two (2) others at 1200 baud. 
As more NOSINABOX implementations become 
available and are placed into service, the additional 
performance information obtained will be used to 
further redesign and optimize the internal data han- 
dling algorithms, thus providing additional perfor- 
mance improvements. 


We do not currently fully understand all of the rela- 
tionships of hardware architecture, processor fami- 
ly, and protocol &sign on the real aggregate 
throughput of NOSINABOX packet switches. Gain- 
ing and documenting additional knowledge in this ar- 
ea will help potential customers make intelligent de- 
cisions about which switch to buy for a given envi- 
ronment, in addition to fueling continued 
performance enhancements. 


Different approaches to the “terminal server” func- 
tionality provided by NOSINABOX have been pro- 
posed, including a suggestion by WB6RQN that 
AX.25 users be treated to an automatic, blind 
"rlogin” connection a local Unix server when a con- 
nection to the local switch is established. These 
ideas deserve further investigation, and it is likely 
that a future release of NOSINABOX will provide 
support for multiple approaches to solving the con- 
tinuing problem of AX.25 support in a computer-to 
computer networking environment, with some mech- 
anism provided to configure the mechanism desired 
for a given local area 
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Conclusion 


This paper has discussed issues related to use of the 
KA9Q "NOS" TCP/IP software in a standalone, ama- 
teur packet radio packet switch environment. Current 
status and future directions of the authors’ efforts in 


this area have been reported. 


For continuing progress reports and other informa- 
tion about the effort to develop intelligent packet 
switch systems, the reader is directed to “Packet Sta- 
tus Register”, the newsletter of TAPR, the Tucson 
Amateur Packet Radio organization. The authors 
may be reached by a variety of means, listed below. 


We strongly encourage you to provide feedback on 
the ideas expressed in this paper, and encourage you 
to acquire and experiment with one or more of the 
packet switch platforms discussed, and report your 
experiences to us 
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